Subject: 15/16 Byte Netbios Names

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Thu, 16 Jun 94 07:52:28 EDT

My comments are indicated with a ====>.

Steve

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Steve, Ravi and Robin,
>
>Thanks for all your feedback on my suggested handling for Netbios circuits.  I
>think it is possible to achieve a win-win combination of all the ideas by
>recognizing that we have been addressing two different problems: name caching
>and the matching of NQ/NR requests.

====> Paul, I agree that we are really talking about two different issues
====> here: NETBIOS name caching and treating all 16 bytes of a NETBIOS
====> name as significant in NAME_QUERYs and NAME_RECOGINIZED.

>
>We should use 16-byte name significance as the default in the matching of NQ/NR
>messages, with retries absorbed at the origin and issued at the target DLSw for
>each (16-byte) name.   This has the advantage of limiting the number of NQ
>messages to 2 for the scenario I described in the previous mail. (You can't get
>any better than this without building knowledge about the specifics of LANMAN
>and other Netbios stacks into the DLSw - ugh!)  It will also work for any
>Netbios stack that really does use 16-byte names.

====> I agree.  In the LANMAN scenario you described in your June 1st
====> note, the last byte is significant and the search for the name with
====> the x'05' name type must be treated as a different search from the
====> one with the x'03' name type.
>
>Robin's concern about the size of the name cache can be resolved by using
>Ravi's  proposal for determining when to add an entry to the cache.  This would
>add only one 15-byte name to the cache for the same scenario.  If the 16th byte
>is printable (because it is a real 16-byte name), then a 16-byte name cache
>entry is added instead.

====>  I believe the caching strategy should left up to the
====>  implementation.  One must be careful about the 'is the 16th byte
====>  printable?' rule.  NETBIOS provides a NETBIOS_NAME_NUMBER_1 as
====>  the first entry in its name table.  It consists of 10 bytes of
====>  binary zeros followed by the adapter's universally administered
====>  address.  I have seen these names flowing in NETBIOS networks.
====>  If you use this method for name caching make sure that the first
====>  several bytes are not zeros.
====>
====>  I propose that we make some sort of statement about name caching
====>  that says we forward the first NAME_QUERY for a unique 16 byte
====>  name and absorb the retries of that particular search.
====>
====>  Is there anyone out there that thinks NETBIOS name caching should
====>  be optional?
>
>Does this look OK to all of you?
>
>I have attached some more detailed responses to specific points raised in your
>mails below.
>
>See you in Raleigh,
>
>Paul Brittain
>Data Connection.